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(54) IEEE 1 394 Set Top Box device driver 



(57) A device interface for use in a receiver/decoder 
for a broadcast digital television system in which 
received signals are passed through a receiver to the 
receiver/decoder and thence to a television set. The 
receiver/decoder decodes a compressed MPEG-type 
signal, and is controlled by a remote controller handset, 
through an interface in the receiver/decoder. The opera- 
tion of the receiver/decoder is controlled by a virtual 
machine (VM) which includes a run time engine (RTE). 
The receiver/decoder includes a plurality of interfaces to 
external units. The device interface enables an applica- 
tion run by the RTE to access an IEEE 1394 interface. 
The device driver may be applied to other interfaces. 
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Description 

The present invention relates to interlacing of appli- 
cation programs to physical devices (peripherals), par- 
ticularly but not exclusively in the context of s 
receiver/decoders for digital television systems. 

The advent of digital transmission systems 
intended primarily for broadcasting television signals, in 
particular but not exclusively satellite television sys- 
tems, has opened up the possibility of using such sys- 10 
terns for other purposes. One of these is to provide 
interactivity with the end user. 

The present invention finds specific application in a 
broadcast digital television system in which received 
signals are passed through a receiver to a is 
receiver/decoder and thence to a television set. The 
receiver/decoder decodes a compressed MPEG-type 
signal into a television signal for the television set. It is 
controlled by a remote controller handset, through an 
interface in the receiver/decoder, also known as a set- 20 
top-box or STB. 

One way of providing the interactivity described 
above is to run an application on the receiver/decoder 
through which the television signal is received. It is 
desirable to enable a variety of applications to commu- 25 
nicate with a variety of physical devices in a transparent 
manner. Our co-pending applications PCT/EP97/021 15 
and PCT/EP97/021 1 6 describe systems in which one or 
more applications can be downloaded by a 
receiver/decoder and communicate with physical 30 
devices in the receiver/decoder such as parallel and 
serial interfaces and smartcard readers by means of a 
device driver for each device and an overall device man- 
ager. 

Pursuant to the present invention, it has been pro- 35 
posed to provide the capability for a receiver/decoder to 
communicate with other audio-visual equipment, for 
example, a digital video recorder over a high-speed dig- 
ital interface. The recently developed IEEE 1394 stand- 
ard provides a promising and flexible interface protocol, 40 
providing serial communication rates of 100Mbit/s or 
more. 

A problem with using the IEEE 1 394 interface is that 
the interface bus may be reset or the parameters altered 
by a device connected to the bus other than the 45 
receiver/decoder, and this may cause problems for an 
application. This may lead to a requirement for greater 
memory and processing power to run more complex 
applications capable of dealing with the interface. This 
would add both to the cost of each receiver/decoder and so 
also to the cost of developing and debugging applica- 
tions. 

Aspects of the invention attempt to alleviate the 
problems of interfacing applications to such interfaces. 
Although the invention offers most advantages in inter- 55 
facing a receiver/decoder to an IEEE 1394 or the like 
interface, it will be appreciated that the invention can be 
applied to int rfacing other applications to interfaces 



whose parameters may change outside the control of 
the application. 

In a first aspect, the invention provides a method of 
communicating data, via a device driver, between an 
application and an interface having at least one feature 
to which an interface identifier is assigned, the or each 
interface identifier being liable to change after at least 
one event, the method comprising: 

for at least one said feature, storing a correspond- 
ing logical identifier; 

providing the logical identifier to the application for 
directing communication associated with the corre- 
sponding feature between the device driver and the 
application; 

maintaining correspondence between the or each 
logical identifier and the or each feature independ- 
ently of the interface identifier assigned to the or 
each feature so that communication between the 
application and the device driver directed using a 
given logical identifier remains associated with the 
corresponding given feature following a change in 
the assignment of the corresponding interface iden- 
tifier to the feature. 

In this way, although the association of interface 
identifiers and features may change from time to time, 
such changes can be made substantially transparent to 
the application, which can consequently be simpler. 

Communication between the 1 interface and the 
device driver is preferably directed based on the or each 
interface identifier; this facilitates communication with 
the interface. 

Logical identifiers may be assigned only to features 
which are specified by one or more applications. This 
may reduce the number of logical identifiers required. 

Alternatively, the device driver may be arranged to 
compile a list of logical identifiers and corresponding 
interlace identifiers for all said features, or for all fea- 
tures meeting predetermined criteria, and preferably to 
update this list each time a feature is added or removed 
or altered, or if any interface identifier is changed. 

Although the method removes the need for the 
application to know the interface identifier, preferably 
the device driver is arranged to communicate the inter- 
face identifier assigned to a logical identifier to the appli- 
cation on request. This is found to facilitate testing of a 
system remarkably, as it is possible for a high-level 
application to determine whether the interface and 
associated device driver is functioning as desired. 

Preferably, the device driver is arranged to accept 
requests from an application to define connections 
between physical devices connected to the bus using at 
least one logical identifier in place of an interface identi- 
fier. This may facilitate management of connections by 
an application. 

The application is preferably arranged to communi- 
cate with the device driver via device manager means. 
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Provision of device manager means allows overall con- 
trol of communication to be effected, so that multiple 
applications may communicate with multiple devices 
without conflict. 

In a first preferred implementation, at least one said s 
feature of the interface comprises a peripheral con- 
nected to the interface and the corresponding interface 
identifier comprises the physical address (also some- 
times known as a node address) assigned to that 
peripheral, the logical identifier comprising a logical 10 
address (which may also be termed a logical peripheral 
identifier) assigned to the peripheral. Thus, an applica- 
tion using a given logical address can continue to com- 
municate with a given peripheral (for example a digital 
video recorder), even if the physical address of the 15 
peripheral changes (for example following connection of 
another peripheral to the bus and subsequent bus 
reset). 

In such a case, maintaining correspondence prefer- 
ably includes interrogating each peripheral to which a 20 
logical address is assigned to determine the physical 
address assigned to the peripheral following the or each 
event, for example a bus reset. This enables the assign- 
ments to be updated following any likely change in phys- 
ical address. 25 

Also in such a case, it is particularly advantageous 
if communicating the interface identifier for a given 
peripheral comprises communicating the physical (or 
node) address of the peripheral and also includes com- 
municating a further identifier of the peripheral, for 30 
example a unique node identifier containing further 
information identifying the peripheral. The unique node 
identifier may identify the manufacturer and/or vendor 
and/or model number of the peripheral, and may include 
a serial number. The unique node identifier is preferably 35 
at least 4 bytes, and more preferably 8 bytes long. 

According to a second preferred implementation, at 
least one said feature of the interface comprises a chan- 
nel of defined parameters available via the interface and 
the corresponding interface identifier comprises the 40 
interface channel number (or so-called channel identi- 
fier), the logical identifier comprising a logical channel 
identifier. In this way, it is not necessary for the applica- 
tion to keep track of interface channel numbers, which 
may change. The channels are preferably isochronous 45 
channels having a defined bandwidth. 

Preferably the device driver is arranged to receive a 
request from an application to allocate a channel of 
defined parameters (for example a channel having a 
defined maximum bandwidth) and to return a logical so 
channel identifier if allocation is successful. Although 
the application need not know the interface channel 
number, it is preferable if the device driver is arranged to 
accept a preferred interface channel number and to allo- 
cate the preferred interface channel if available, and to 55 
allocate a free channel if the preferred interface channel 
is not available or if no preferred interface channel is 
specified. Provision of the ability to specify interface 



channels may facilitate control and testing of the inter- 
face by a suitable application, without requiring all appli- 
cations to recognise interface channel numbers. 
Preferably the device driver is arranged to receive an 
identifier of a preferred interface channel, and to recog- 
nise a predetermined key in place of a valid interface 
channel number as specifying no preferred interface 
channel but to report an error to the application if other 
invalid interface channel numbers are specified; this 
may assist in debugging applications. 

It is also preferable that the device driver is 
arranged to communicate the interface channel identi- 
fier to the application, and preferably also other param- 
eters, preferably including at least one of the maximum 
rate allocated to the channel, the rate currently availa- 
ble, the number of connections (if any) using the chan- 
nel, and the identifiers of each connection using the 
channel. This enables sophisticated management of 
communications by a suitable application, without 
requiring ail applications to deal with such parameters 
to use the interface. 

Most preferably, the first and second preferred 
implementations are both employed together, the 
device driver being arranged to accept requests from an 
application to define one or more connections between 
peripherals attached to the interface by reference to log- 
ical addresses and logical channel identifiers. Combina- 
tion of the two implementations in this way provides the 
synergistic benefit that an application is able to estab- 
lish connections without needing to keep track of any 
details of the physical addreps of the peripherals con- 
cerned or the interface channel over which the connec- 
tion is established. Preferably, the device driver is 
arranged to establish at least one of point-to-point con- 
nections between specific peripherals and broadcast 
connections. 

During an event, such as a bus reset, in which inter- 
face parameters are liable to change, communication 
may be interrupted. Although the device driver may han- 
dle certain events without requiring input from the appli- 
cation, it is preferable that the device driver is arranged 
to signal one or more events to an application (if the 
application so requests), the events preferably including 
at least one of reset of the bus (preferably separate 
events signalling beginning and end of reset), a change 
in bus topology or channel or connection parameters. 

In a second aspect, the invention provides a device 
driver for effecting communication between an applica- 
tion and an interface having at least one feature to 
which an interface identifier is assigned, the or each 
interface identifier being liable to change after at least 
one event, the device driver comprising: 

means for storing at least one logical identifier cor- 
responding to a respective interface identifier; 
means for providing the logical identifier to the 
application for directing communication associated 
with the corresponding f ature between the device 
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driver and the application; 
means for maintaining correspondence between 
the or each logical identifier and the or each feature 
independently of the interface identifier assigned to 
the or each feature so that communication between s 
the application and the device driver directed using 
a given logical identifier can remain associated with 
the corresponding given feature following a change 
in the assignment of the corresponding interface 
identifier to the feature. w 

The device driver may be implemented in hardware, 
for example in a dedicated integrated circuit; this may 
provide enhanced speed of operation. More preferably, 
however, the device driver is implemented at least partly 15 
in software, preferably run by processing means which 
runs the application; this allows greater flexibility, 
requires less components, and allows the device driver 
to be updated more readily. 

In a third aspect, the invention provides a data 20 
processing system comprising run-time engine means 
for running an application; 



interface means for connection to at least one 
device, the interface having at least one feature to 
which an interface identifier is assigned, the or each 
interface identifier being liable to change after at 
least one event; 

device driver means comprising: 
means for storing at least one logical identifier cor- 
responding to a respective interface identifier; 
means for providing the logical identifier to the 
application for directing communication associated 
with the corresponding feature between the device 
driver and the application; 
means for maintaining correspondence between 
the or each logical identifier and the or each feature 
independently of the interface identifier assigned to 
the or each feature so that communication between 
the application and the device driver directed using 
a given logical identifier can remain associated with 
the corresponding given feature following a change 
in the assignment of the corresponding interface 
identifier to the feature. 

Preferred features of the first aspect may be applied 
to the second and third aspects. 

The data processing system is preferably imple- 
mented in a receiver/decoder (for example a set-top- 
box) which includes means for receiving broadcast data 
(via satellite or cable), the interface preferably being 
arranged for connection to a digital video recorder or 
digital display device or computer for display or storage 
of at least a portion of the received data. The device 
driver means is preferably arranged to cooperate with 
device means for modifying the received data stream to 
produce a modified data stream for passing to said 
interface. 



The interface preferably conforms to the IEEE 1 394 
standard or a modification, refinement or variation 
thereof. Data may be transported according to the IEEE 
1883 standard. 

The application is preferably run in an interpreted 
language and the device driver is preferably compiled. 

The invention is most preferably employed in a 
receiver/decoder for enabling an application to commu- 
nicate with, for example, a digital video recorder over an 
IEEE 1394 bus. The device driver may be arranged to 
transmit commands for controlling the digital video 
recorder from the application and/or to receive data 
concerning the information stored on the digital video 
recorder; in this way an interactive application running 
in the receiver/decoder may control recording and play- 
back of programs or other data. The data to be commu- 
nicated is preferably MPEG format (by which is meant 
any variant or development of the basic MPEG format) 
data, but other formats may be used. 

Preferred features of the present invention will now 
be described, purely by way of example, with reference 
to the accompanying drawings, in which:- 

Figure 1 is a schematic diagram of interfaces of a 
receiver/decoder; 

Figure 2 is a functional block diagram of the 
receiver/decoder; 

Figure 3 shows certain comppnents of the virtual 
machine and run time engine in more detail; 

Figure 4 is a schematic diagram for explaining the 
flow of communication between an application and 
a remote peripheral via the device driver; 

Rgure 5 is a schematic diagram illustrating some 
components of the device driver. 



40 RECEIVER/DECODER BASICS 

Before describing a device driver embodying the 
invention, the basic features of the preferred platform, a 
digital satellite receiver/decoder, will be explained 
45 briefly. 

Referring to Fig. 1, a receiver/decoder 2020 or set- 
top-box for use in a digital interactive television system 
in which the device driver of the embodiment is intended 
to be installed is schematically depicted. Details of a 

so suitable digital interactive television system may be 
found in our co-pending applications PCT/EP97/02106 - 
0211 7 to which reference should be made, and the dis- 
closures of which are herein incorporated by reference. 
For ease of reference, parts described in more detail in 

55 the aforementioned specifications ar g nerally desig- 
nated by the reference numerals used in those specifi- 
cations. The basic arrangement of the receiver/decoder 
will be summarised below, to assist in understanding 
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the function of the device driver. 

As described in more detail in the aforementioned 
specifications, referring to Figure 1, the 
receiver/decoder 2020 includes several interfaces; spe- 
cifically, a tuner 4028 for the MPEG signal flow, a serial s 
interface 4030, a parallel interface 4032, and two card 
readers 4036, one for a smartcard forming part of the 
system and one for bank cards or other smart cards 
(used for making payments, home banking, etc). The 
receiver/decoder also includes an interface 4034 to a 10 
modemmed back channel 4002 to the television signal 
producer, so that the user can indicate preferences, etc 
back to the television signal (programme) producer. The 
receiver also comprises a Run-Time-Engine 4008, a 
Device Manager 4068 and a plurality of Devices 4062 is 
for running one or more applications 4056. 

For the purposes of this specification, an applica- 
tion is a piece of computer code for controlling high level 
functions of preferably the receiver/decoder 2020. For 
example, when the end user positions the focus of a 20 
remote controller on a button object seen on the screen 
of the television set 2022 and presses a validation key, 
the instruction sequence associated with the button is 
run. 

An interactive application proposes menus and exe- 25 
cutes commands at the request of the end user and pro- 
vides data related to the purpose of the application. 
Applications may be either resident applications, that is, 
stored in the ROM (or FLASH or other non-volatile 
memory) of the receiver/decoder 2020, or broadcast. 30 
and downloaded into the RAM or FLASH memory of the 
receiver/decoder 2020. 

Some examples of applications, described in more 
detail in the aforementioned applications are:- 

35 

• An Initiating Application which is an adaptable col- 
lection of modules enabling the receiver/decoder 
2020 to be immediately operative in the MPEG-2 
environment. 

• A Startup Application which allows any application, 40 
either downloaded or resident, to run on the 
receiver/decoder 2020. 

• A Program Guide which is an interactive application 
which gives full information about programming. 

• A Pay Per View application which is an interactive 45 
service available on each PPV channel of the digital 

TV bouquet to enable the end user to buy the cur- 
rent event. 

• A PC Download application enabling an end user to 
download computer software using the PC down- so 
load application. 

• A Magazine Browser application comprising a 
cyclic video broadcast of images with end user nav- 
igation via on-screen buttons. 

• A Teleshopping application enabling offers of goods 55 
for sale to be transmitted to the receiver/decoder 
2020 and displayed on the television 2022 and ena- 
bling the user to select a particular item to buy. 



Applications are stored in memory locations in the 
receiver/decoder 2020 and represented as resource 
files. The resource files comprise graphic object 
description unit files, variables block unit files, instruc- 
tion sequence files, application files and data files, as 
described in more detail in the above mentioned speci- 
fications. 

In the MPEG data stream, each module comprises 
a group of MPEG tables. Each MPEG table may be for- 
matted as a number of sections. In the MPEG data 
stream, each section has a "size" 6f up to 4 kbytes. For 
data transfer via the serial and parallel port, for exam- 
ple, modules similarly are split into tables and sections, 
the size of the section varying with the transport 
medium. 

Modules are transported in the MPEG data stream 
in the form of data packets of typically 188 bytes within 
respective types of data stream, for example, video data 
streams, audio data streams and teletext data streams. 
Each packet is preceded by a Packet Identifier (PID) of 
13 bits, one PID for every packet transported in the 
MPEG data stream. A programme map table (PMT 
table) contains a list of the different data streams and 
defines the contents of each data stream according to 
the respective PID. A PID may alert a device to the pres- 
ence of applications in the data stream, the PID being 
identified using the PMT table. 

The decoder contains memory divided into a RAM 
volume, a FLASH volume and a ROM volume, but this 
physical organization is distinct from the logical organi- 
zation. The memory may further be divided into mem- 
ory volumes associated with the various interfaces. 
From one point of view, the memory can be regarded as 
part of the hardware; from another point of view, the 
memory can be regarded as supporting or containing 
the whole of the system shown apart from the hardware. 

The system can be regarded as centred on a run 
time engine 4008 forming part of a virtual machine 
4007. This is coupled to applications on one side (the 
"high lever side), and, on the other side (the "low level" 
side), via various intermediate logical units discussed 
below, to the receiver/decoder hardware 4061. The 
receiver/decoder hardware can be regarded as includ- 
ing the various ports or interfaces as discussed above 
(the interface 2030 for the handset 2026, the MPEG 
stream interface 4028, the serial interface 4030, the 
parallel interface 4032, the interfaces to the card read- 
ers 4036, and the interface 4034 to the modemmed 
back channel 4002). 

With reference to Figure 2, various applications 
4057 are coupled to the unit 4007; some of the more 
commonly used applications may be more or less per- 
manently resident in the system, as indicated at 4057, 
while others will be downloaded into the system, eg 
from the MPEG data stream or from other ports as 
required. 

The unit 4007 includes, in addition to the run time 
engine 4008, some resident library functions 4006 
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which include a toolbox 4058. The library contains mis- 
cellaneous functions in C language used by the engine 
4008. These include data manipulation such as com- 
pression, expansion or comparison of data structures, 
line drawing, etc. The library 4006 also includes infor- 5 
mation about firmware 4060 in the receiver/decoder 
2020, such, as hardware and software version numbers 
and available RAM space, and a function used when 
downloading a new device 4062. Functions can be 
downloaded into the library, being stored in Flash or 10 
RAM memory. 

The run time engine 4008 is coupled to a device 
manager 4068 which is coupled to a set of devices 4064 
which are coupled to device drivers 4060 which are in 
turn coupled to the ports or interfaces. In broad terms, a is 
device driver can be regarded as defining a logical inter- 
face, so that two different device drivers may be coupled 
to a common physical port. A device will normally be 
coupled to more than one device driver; if a device is 
coupled to a single device driver, the device will nor- 20 
mally be designed to incorporate the full functionality 
required for communication, so that the need for a sep- 
arate device driver is obviated. Certain devices may 
communicate among themselves. 

As will be described below, there are 3 forms of 25 
communication from the devices 4064 up to the run time 
engine: by means of variables, buffers, and events 
which are passed to a set of event queues. 

Each function of the receiver/decoder 2020 is rep- 
resented as a device 4062. Devices can be either local 30 
or remote. Local devices 4064 include smartcards, 
SCART connector signals, modems, serial and parallel 
interfaces, a MPEG video and audio player and an 
MPEG section and table extractor. Remote devices 
4066, executed in a remote location, differ from local 3s 
devices in that a port and procedure must be defined by 
the system authority or designer, rather than by a device 
and device driver provided and designed by the 
receiver/decoder manufacturer. 

When a new device 4062 is created, it can be 40 
installed in existing receiver/decoders 2020 by down- 
loading the relevant application 4056 from the broad- 
cast centre. This downloading is performed in the 
receiver/decoder 2020 by an application 4056 which 
checks the hardware and software versions and, if cor- 45 
rect, loads the software module representing the new 
device 4062 and asks a procedure of the library 4006 to 
install the new device code within the firmware (in Flash 
memory). This can provide a flexible and secure instal- 
lation of new functions within the receiver/decoder 2020 so 
without affecting the rest of the software. 

The device manager 4068 is a common software 
interface between the application 4056 and the specific 
functions of the receiver/decoder 2020. The device 
manager 4068 controls access to devices 4062, 55 
declares receipt of an unexpected event, and manages 
shared memory. 

The run time engine 4008 runs under the control of 



the microprocessor and a common application pro- 
gramming interface. They are installed in every 
receiver/decoder 2020 so that all receiver/decoders 
2020 are identical from the application point of view. 

The engine 4008 runs applications 4056 on the 
receiver/decoder 2020. It executes interactive applica- 
tions 4056 and receives events from outside the 
receiver/decoder 2020, displays graphics and text, calls 
devices for services and uses functions of the library 
4006 connected to the engine 4008 for specific compu- 
tation. 

The run time engine 4008 is an executable code 
installed in each receiver/decoder 2020, and includes 
an interpreter for interpreting and running applications. 
The engine 4008 is adaptable to any operating system, 
including a single task operating system (such as MS- 
DOS). The engine 4008 is based on process sequencer 
units (which take various events such as a key press, to 
carry out various actions), and contains its own sched- 
uler to manage event queues from the different hard- 
ware interfaces. It also handles the display of graphics 
and text. A process sequencer unit comprises a set of 
action-groups. Each event causes the process 
sequencer unit to move from its current action-group to 
another action-group in dependence on the character of 
the event, and to execute the actions of the new action- 
group. 

The engine 4008 comprises a code loader to load 
and download applications 4056 into the 
receiver/decoder memory 2028. Only the necessary 
code is loaded into the RAM or Flash memory, in order 
to ensure optimal use. The downloaded data is verified 
by an authentication mechanism to prevent any modifi- 
cation of an application 4056 or the execution of any 
unauthorized application. The engine 4008 further com- 
prises a decompressor. As the application code (a form 
of intermediate code) is compressed for space saving 
and fast downloading from the MPEG-2 transport 
stream or via a built-in receiver/decoder mode, the code 
must be decompressed before loading it into the RAM. 
The engine 4008 also comprises an interpreter to inter- 
pret the application code to update various variable val- 
ues and determine status changes, and an error 
checker. 

Before using the services of any device 4062, a 
program (such as an application instruction sequence) 
has to be declared as a "client", that is, a logical access- 
way to the device 4066 or the device manager 4068. 
The manager gives the client a client number which is 
referred to in ail accesses to the device. A device 4066 
can have several clients, the number of clients for each 
device 4066 being specified depending on the type of 
device 4066. A client is introduced to the device 4066 by 
a procedure "DeviceJDpen Channel". This procedure 
assigns a client number to the client. A client can be 
taken out of the device manager 4068 client list by a 
procedure "Device_Ciose Channel". 

The access to d vices 4062 provided by the device 
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manager 4068 can be either synchronous or asynchro- 
nous. For synchronous access, a procedure "Device: 
Call" is used. This is a means of accessing data which 
is immediately available or a functionality which does 
not involve waiting for the desired response. For asyn- 5 
chronous access, a procedure "Device: I/O" is used. 
This is a means of accessing data which involves wait- 
ing for a response, for example scanning tuner frequen- 
cies to find a multiplex or getting back a table from the 
MPEG stream. When the requested result is available, 10 
an event is put in the queue of the engine to signal its 
arrival. A further procedure "Device: Event" provides a 
means of managing unexpected events. 

As noted above, the main loop of the run time 
engine is coupled to a variety of process sequencer 15 
units, and when the main loop encounters an appropri- 
ate event, control is temporarily transferred to one of the 
process sequencer units. 

Referring to Fig. 3, the device manager includes a 
queue 100 into which events from the devices are 20 
passed for temporary storage. At suitable intervals, the 
virtual machine sends a signal to this queue to extract 
the first item from it. This event item is moved to a queue 
structure 101 in the virtual machine. Depending on the 
priority level of the event item, it is inserted into the 25 
appropriate one of the 5 queues 0 to 4. Event items are 
extracted from the queue structure 101 by a queue 
selector unit 102 under the control of the run time 
engine. 

When an event is selected from the queue structure 30 
101, it is passed to a process sequencer unit engine 
104, which consists of a process sequencer unit driver 
105 and a set of process sequencer units 106. Each 
process sequencer unit is a set of action-groups linked 
together, so that each step from one action-group to the 35 
next action-group is, in general, dependent on the cur- 
rent action-group and the nature of the event. Different 
process sequencer units have different sizes and com- 
plexities, including one in which the "next" action-group, 
ie the action-group to which the system steps on in 40 
response to an event, is dependent solely on the nature 
of the event but is independent of the current action- 
group. Also, as is shown at the right-hand side of the 
process sequencer units block, there may be several 
copies of a process sequencer unit, ie several identical 45 
process sequencer units, to deal eg with several sepa- 
rate data streams using identical protocols through a 
single port. 

When an event is selected, it is passed to the 
appropriate process sequencer unit. This selects the so 
appropriate outlet from the current action-group on the 
process sequencer unit. This results in the appropriate 
next action-group being selected and the actions in that 
action-group being performed, involving eg the sending 
of a message to the device manager or the execution of ss 
a instruction sequence. Action-groups in the process 
sequencer unit can also send event messages to other 
process sequencer units. 



If a instruction sequence is selected, the identifica- 
tion of the instruction sequence is sent to a instruction 
sequence selector 107. This obtains the desired 
instruction sequence from a instruction sequence mem- 
ory 108 and passes it to a instruction sequence inter- 
preter 109, which executes the instruction sequence. 

The system also includes a filter 110, which is 
loaded with event types eg from the process sequencer 
units 1 06. When an event item is passed from the queue 
100 inthedevice manager to the queue structure 101 in 
the virtual machine, its type or character is matched 
against the list in the filter 1 1 0, and if it is of a type which 
is not recognized, it is rejected. This ensures that if say 
the device manager or the keyboard generates events 
of a type which the virtual machine cannot deal with, 
those events are not passed to the queue structure 1 01 . 
(If events of this kind were passed to the queue struc- 
ture 101, either they would accumulate in that queue 
structure or they might cause malfunctioning of the 
process sequencer unit engine 104.) 

Thus, it can be seen that our basic 
receiver/decoder platform provides considerable flexibil- 
ity in enabling an application to communicate with a 
variety of devices. 

DEVICE DRIVER FOR IEEE 1394 BUS 

Referring to Fig. 4, it can be seen that the IEEE 
1394 bus driver operates according to the above 
described scheme to facilitate communication between 
an application and a peripheral such a digital video 
recorder connected to the I EEE 1 394 bus. 

For high speed communication of data, for example 
for storage of MPEG real-time data, conventional serial 
and parallel interfaces, which are relatively straightfor- 
ward to control by an application, may not be fast 
enough. The device driver described below incorpo- 
rates a number of novel features which enable an appli- 
cation to access the IEEE 1394 bus efficiently, and may 
enable control of, for example, a digital video recorder 
connected to the bus by a relatively unsophisticated 
application. 

The device driver can be considered as comprising 
a number of functional units which are separately 
accesible by an application, hereinafter termed com- 
mands. Each command interfaces with an application 
via a device 4062 run under the control of the device 
manager 4068 by means of one of the three standard 
procedures mentioned above, which are common to 
other devices. Information may be passed between an 
application and the device driver by means of parameter 
tables. For ease of reference, the three basic proce- 
dures are summarised briefly below:- 

1) Device: Call. This command can be used by an 
application for performing synchronous commands 
or data transfer. Execution of the application is sus- 
pended until control is returned when the operation 
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by the device driver has completed; this allows 
operations which must be performed in strict 
sequence to be controlled reliably. 

2) Device: I/O. This command allows asynchronous s 
operation. That is, an application can send a 
request for a data transfer or a particular function to 
be performed by the device driver and execution of 
the application can continue while the data transfer 

or function is performed by the device driver. 10 

3) Device: Event. This event trapping function ena- 
bles events to be signalled by the device driver to 
an application, and for particular action to be taken 

by the application in response to the event inde- is 
pendently of the code the application is executing at 
the time the event is signalled; effectively the appli- 
cation is interrupted. Events may be prioritised. 
Events may be used to signal events occurring on 
the interface, such as a bus reset. 20 

The commands provided in a device driver embod- 
ying the invention will now be described. Each com- 
mand may be accessed by an application by passing an 
identifier of the command as a parameter via either the 2s 
Device: Call or Device: 10 problems. Not all of the com- 
mands described below need be provided, and the 
functions of the commands may be altered. Although 
the commands may be independently provided or 
altered, as will be appreciated, certain synergistic bene- 30 
fits accrue from the combined functionality provided by 
the commands described. 

The commands will be described in terms of the 
features and functions provided by each command, as 
seen by an application, together with optional and pref- 35 
erable features. With the information given and specifi- 
cations provided, actual implementation of these 
features should be straightforward for one skilled in the 
art, and the precise details are left to the implementor. 
As an example, each command could be implemented 40 
in software, preferably written in the C programming lan- 
guage and preferably compiled to run on the processor 
used to run the application; however the device driver 
may be run on a separate processor, and some or all 
commands may be implemented by dedicated hard- 45 
ware. Using the Call or 10 commands, the device driver 
may signal information or pass parameters back to an 
application by setting values in a parameter table stored 
in memory whose address is passed to the device 
driver. 50 

it will be appreciated that the functionality 
described below for the commands implies certain 
underlying functions to be implemented by the device 
driver, for example, to deal with logical peripheral identi- 
fiers and logical channel identifiers, the device driver 55 
incorporates means for maintaining respective tables of 
logical peripheral identifiers and logical channel identifi- 
ers enabling them to be correlated to their correspond- 



ing interface features (physical address or interface 
channel number respectively). In addition, in the event 
of an occurrence isuch as a bus reset, the device driver 
is arranged to ascertain the new physical addresses 
arid channel numbers and to update the tables so that 
transition is relatively seamless as' seen by an applica- 
tion. 

In addition, of course, the device driver includes 
means for actually effecting communication with the 
interface and for performing necessary housekeeping 
tasks such as memory allocation and de-allocation. 
Some of these functions are schematically illustrated in 
Fig. 5. The details of these will depend on the specific 
physical hardware used, but will be straightforward for 
one skilled in the art to implement based on the guid- 
ance presented in this specification, and with reference 
to the appropriate portions of the IEEE 1394 standards 
documentation (the disclosure of which is herein incor- 
porated by reference), so will not be described here. 

Command: Bus 1394 Set 

This command enables basic interface parameters 
to be set by an application, preferably the size of a data 
reception buffer that should be allocated and the 
number of communication retries to be used when 
sending asynchronous commands via the interface. 
These parameters could be pre-set and the command 
omitted, but provision of this command enables commu- 
nications to be optimised for different applications. 
Although such parameters could very well be set asyn- 
chronously, it is found preferable to access this com- 
mand via the Call method, so that subsequent 
application commands are only executed after the 
device parameters have been stabilised. The command 
preferably signals an error to the application if the 
device driver is in the process of receiving data from a 
peripheral. 

Command: Bus 1394 Info 

This command returns basic information concern- 
ing bus topology to an application. Because it is less 
time-critical, it is preferably accessed asynchronously 
via the IO command. 

Preferably, this and indeed all or at least some 
asynchronous commands are arranged to pass a maxi- 
mum time (for example in ms) required for response (or 
a code, for example zero signifying no maximum time); 
this may enable the device driver to prioritise requests. 

Preferably the command returns information con- 
cerning the maximum data rate managed by the bus, 
the data rate available at the moment of the call (that is, 
taking into account connections already active on the 
bus), the number of peripherals physically connected to 
the bus and their corresponding logical identifiers (to be 
discussed further below), and which logical channels 
are available at the time of the call. 
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With the IEEE 1394 bus, each peripheral con- 
nected to the bus is assigned a physical address which 
may change from time to time. 

It will be appreciated that, although specific provi- 
sion of this command is optional, it is desirable that the 
device driver maintains a table of logical addresses 
(also termed logical peripheral identifiers) which are 
constant for each peripheral (for a given session for a 
given application; the logical addresses may change if 
the receiver/decoder is re-set), so that on each execu- 
tion, an application can use a single logical address to 
identify a corresponding peripheral uniquely and unam- 
biguously. The channel numbers assigned to channels 
may also vary, so the device driver also maintains a 
table of logical channel numbers. The device driver may 
then respond to an information request simply by look- 
ing up data from the appropriate table. 

Preferably, information concerning the availability of 
channels is passed in binary form, as a bitmap, prefera- 
bly 8 bytes of information in which each bit encodes the 
availability of one of 64 logical channels (for example a 
"0" signifying that the channel is already allocated and a 
"1" signifying that the channel is available for use). 

Command: Bus 1394 Info Periph 

This command is arranged to receive a parameter 
indicating a logical peripheral identifier and to return a 
two-byte physical address (also known as a node ID) 
corresponding to the physical address assigned to the 
peripheral on the interface, and preferably also to return 
an 8 byte unique node identifier preferably uniquely 
identifying the peripheral globally, or at least identifying 
the vendor or model number of the peripheral. This pro- 
vides the capability for a suitably sophisticated applica- 
tion to determine, for example, special capabilities of the 
equipment based on information identifying specific 
peripherals. 

The command is preferably arranged to signal an 
error if the interface is not physically connected to a 
functional IEEE 1394 bus or if the logical peripheral 
identifier is invalid (for example greater than a predeter- 
mined maximum, preferably 63), and also to signal a 
pending bus reset, an error if the specified logical 
peripheral identifier is not known, or if the device fails to 
respond within a specified time. 

The command is preferably accessed asynchro- 
nously, by means of the Device: I/O procedure, a signal 
indicating completion or failure being passed by means 
of a parameter block. 

Command: Bus 1394 Alloc Channel 

This command is arranged to receive a request to 
allocate a channel, preferably specifying the desired 
communication rate and preferably also the desired 
interface channel to be used. A pre-determined code 
(for example OFFh) may be used to signify that no par- 



ticular interface channel, in which case, or in the case of 
the desired interface channel being occupied, the 
device driver allocates an available channel. 

The command returns an allocated logical channel 

s identifier if successful, and preferably signals an error in 
the applicable cases d scribed above for the 
Bus_1394_lnfo_Periph command, or if no channels are 
available or if the requested data rate is higher than the 
maximum rate available. 

70 In simplified implementations ,of the device driver, 
for example using a very limited number of channels, 
this command, and the related two commands 
described next, may be omitted, at the expense of some 
flexibility. 

15 The command is preferably accessed asynchro- 
nously, by means of the Device: I/O procedure, a signal 
indicating completion or failure being passed by means 
of a parameter block. 

20 Command: Bus 1394 Info Channel 

This command is arranged to return information 
concerning the characteristics of a specified logical 
channel to an application. The command preferably 

25 returns the maximum rate allocated to the channel (in 
Kbit/s), the rate available via the channel at the moment 
of the call, the real channel identifier (that is, the one 
assigned by the interface rather then by the device 
driver), the number of connections using the channel 

30 and the logical identifiers of each connection using the 
channel. 

The command preferably signals an error if the 
specified channel number is not allocated, in the event 
of an invalid identifier, in the case of a pending bus 
35 reset, or if the interface is not physically connected. 

The command is preferably accessed asynchro- 
nously, by means of the Device: I/O procedure, a signal 
indicating completion or failure being passed by means 
of a parameter block. 

40 

Command: Bus 1394 Free Channel 

This command frees a channel for communication 
by breaking down connections for a logical channel 
45 specified as a parameter (but preferably not de-allocat- 
ing the connection identifiers). The command preferably 
operates asynchronously and signals that communica- 
tions are still pending in the selected channel by means 
of an event. 

50 

Command: Bus 1394 Open Connect 

This command is arranged to receive a request 
indicating a logical channel identifier and preferably also 
55 a connection type and to initiate a point-to-point connec- 
tion between two devices or a broadcast in or out con- 
nection depending on the connection type specified. 
Where point-to-point connection is specified, the logical 
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peripheral identifiers of the two peripherals must also be 
passed to the device driver. Although variants of this 
command could operate using physical addresses and 
interface real channel numbers, operation on the basis 
of logical parameters offers the advantages of simplified 5 
application operation mentioned above. 

The command returns a logical connection, identi- 
fier if successful. 

Simplified implementations may omit the capability 
for defined point-to-point connections to be specified; in 10 
typical applications, there may only be a single device 
such as a digital video recorder connected to the bus, 
so broadcast connections may suffice. 

In some implementations of the device driver, open- 
ing of a particular connection may also automatically 15 
trigger re-routing of other signal paths within the 
receiver/decoder. For example opening of a broadcast 
in connection may cause automatic disconnection of the 
front end from the demultiplexer input, so that the 
demultiplexer is available to process incoming data 20 
received over the IEEE 1 394 bus. 

This command preferably signals an error when the 
maximum number of connections is reached, or in the 
other applicable cases mentioned above in relation to 
other commands. 25 

The command is preferably accessed asynchro- 
nously, by means of the Device: I/O procedure, a signal 
indicating completion or failure being passed by means 
of an event. 

30 

Command: Bus 1394 Close Connect 

This command receives a logical connection identi- 
fier and stops communication on that connection, there- 
after freeing the connection identifier for re-use. 35 

If signals are automatically re-routed within the 
receiver/decoder on opening of connections, the device 
preferably restores the connections to their previous 
state on closing the connection, or on closing the last 
relevant connection. For example, the demultiplexer 40 
input may be reconnected to the front end on closure of 
the last broadcast in connection. 

The command is preferably accessed asynchro- 
nously, by means of the Device: I/O procedure, a signal 
indicating completion or failure being passed by means 45 
of an event. 

Command: Bus 1394 List Connect 

This command returns a list of active connections, so 
only those involving the decoder itself, available at the 
time of the call, preferably in the form of a list comprising 
the number of connections and for each connection a 
logical connection identifier and a flag indicating the 
type of connection (point-to-point, broadcast in, broad- ss 
cast out). 

This and/or the command described below may be 
omitted in simple implementations of the d vice, if only 



simple connections are provided. However, provision of 
such commands enables an application to monitor not 
only connections which it has itself established, but also 
to monitor connections established by other applica- 
tions, if more than one application is able to use the 
device driver at any one time, and to monitor whether 
any connections have been unexpectedly closed. 

The command is preferably accessed synchro- 
nously, by means of the Device: Call procedure, as con- 
nections are liable to change frequently and an 
application may otherwise attempt to control communi- 
cations based on out-of date information, or else require 
polling of the response from the device driver. 

Command: Bus 1394 Info Connect 

This command accepts a logical connection identi- 
fier and returns the logical channel number over which 
the connection is established. The command preferably 
also returns an indication of the type of connection, and, 
in the case of a point-to-point connection, returns the 
logical addresses of the peripherals involved. 

As with the List_Connect command, this command 
is preferably accessed synchronously. 

Command: Bus 1394 Reset 

This command initiates a bus reset procedure, or 
returns an error if a bus reset is already pending. The 
command can be used to enable an application to seize 
control of the IEEE 1394 bus immediately after a reset, 
and is preferably accessed synchronously. The device 
driver preferably signals completion of bus reset by 
means of an event, discussed further below. 

Command: Bus 1394 Send FCP 

i 

This command in particular may be omitted or 
implemented differently. The following description is of 
an example of an arrangement for sending data asyn- 
chronously over the IEEE 1394 bus. 

This command receives a parameter block contain- 
ing a message to be sent asynchronously as a com- 
mand or response to a peripheral on the IEEE 1394 
bus. The parameter block preferably contains an indica- 
tion of the type of message, the size of buffer that 
should be allocated for a response, the logical periph- 
eral identifier of the destination peripheral, the length of 
the message and the message itself. 

The command preferably indicates successful 
sending or reports an error if sending was unsuccessful 
within a pre-determined number of retries or in the 
applicable cases described above for the lnfo_Periph 
command. 

Since large amounts of data may potentially be 
transferred, the command is preferably accessed asyn- 
chronously, to allow the application to continue execu- 
tion while the transistor continues. 
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Preferably, the command is arranged to broadcast a 
message to all peripherals if a pre-defined logical 
peripheral identifier is specified, for example 63. 

In simplified implementations of th device driver, 
this command may be restricted to transmission of mes- s 
sage? of fixed length, for example 32 bytes, which is suf- 
ficient for transmission of a command to a digital video 
recorder. 

Preferably, the device driver is capable of receiving 
and transmitting multiple requests quasi-simultane- w 
ously, and of reporting multiple responses. However, 
simplified implementations may only provide capability 
for single sequential requests. 

In addition to the commands, which allow an appli- 
cation to send commands to the device driver, the 15 
device driver is arranged to signal events to an applica- 
tion, via the device manager's event handling functions. 
The device driver implements the following events:- 

Ev Bus 1394 Rev FCP 20 

This event signals reception of an FCP frame from 
a peripheral, and provides a parameter block containing 
the source peripheral logical address, the type, length 
and content of the message. 25 

Ev Bus 1394 Channel 

This event signals channel allocation and dealloca- 
tion, and passes a list signalling which channels are 30 
allocated, preferably encoded in binary form as 
described above in relation to the Info command. 

Ev,PusJ394_CQnfig 

35 

This event signals peripheral connection or discon- 
nection, and provides a list containing the number of 
peripherals connected and their logical addresses. 

It will be appreciated that changes on the interface 
relating to this and the previously described Channel ao 
event must be monitored by the device driver in order to 
keep the correspondence table between logical and 
interface identifiers updated, even if the device driver 
does not signal such events to an application. 

45 

Ev Bus 1394 Connect 

This event is used to signal a connection break, and 
provides a logical identifier to the application of the con- 
nection broken, and preferably also a list containing fur- so 
ther information concerning the broken connection in 
similar format to that described above for the 
I nf o_Con n ecti on command. 

Ev Bus 1394 Lo Events 55 

This event may signal one or more low-level inter- 
face errors, for example peripherals holding the bus for 



longer than permitted, data or CRC errors, unexpected 
transactions, unknown channel numbers or transaction 
codes and the like. This event is primarily useful for de- 
bugging and may be omitted in simplified implementa- 
tions of the devic driver. 

Ev Bus 1394 Hi Events 

This event may signal one or more high-level bus 
conditions, including at least one (and preferably both) 
of a bus reset start and finish, and also events such a 
cable power failure, detection of a loop in the bus, or a 
fatal error from which the device driver cannot recover 
by itself after multiple retries. 

Ev Bus 1394 Off 

As a further event, this event may be used to signal 
errors internal to the device driver, such as not having a 
buffer available in which to store a received message. 

The above commands and events are merely illus- 
trative, and the invention may be implemented in a vari- 
ety of ways, and, in particular, some commands may be 
combined with others which perform similar functions, 
or some may be omitted in simplified implementations. 
Hardware and software implementations of each of the 
functions may be freely mixed, both between com- 
mands and within a single command; hardware imple- 
mentations may operate faster and free up processing 
power, whereas software implementations may be more 
readily updated. It will be readily understood that the 
functions performed by the hardware, the computer 
software, and such like are performed on or using elec- 
trical and like signals. Software implementations may be 
stored in ROM or FLASH, or may be patched in FLASH. 

It will be understood that the present invention has 
been described above purely by way of example, and 
modifications of detail can be made within the scope of 
the invention. 

Each feature disclosed in the description, and 
(where appropriate) the claims and drawings may be 
provided independently or in any appropriate combina- 
tion. 

Claims 

1. A method of communicating data, via a device 
driver, between an application and an interface hav- 
ing at least one feature to which a corresponding 
interface identifier is assigned, the assignment of 
the interface identifier to the feature being suscepti- 
ble to change after at least one event, the method 
comprising: 

for at least one said feature, storing a corre- 
sponding logical identifier; 
providing the logical identifier to the application 
for directing communication associated with 
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the corresponding feature between the device 
driver and the application; 
maintaining correspondence between the or 
each logical identifier and the or each feature 
independently of the interface identifier s 
assigned to the or each feature so that commu- 
nication between the application and the 
device driver directed using a given logical 
identifier remains associated with the corre- 
sponding given feature following a change in 10 
the assignment of the corresponding interface 
identifier to the feature. 

2. A method according to Claim 1 , wherein communi- 
cation between the interface and the device driver 15 
is directed based on the or each interface identifier. 

3. A method according to any preceding claim, includ- 
ing compiling a list of logical identifiers and corre- 
sponding interface identifiers for all features 20 
meeting pre-determined criteria. 

4. A method according to any preceding claim, 
wherein the device driver is arranged to communi- 
cate the interface identifier assigned to a logical 25 
identifier to the application on request. 

5. A method according to any preceding claim, 
wherein the device driver is arranged to accept 
requests from an application to define connections so 
between physical devices connected to the bus 
using at least one logical identifier in place of an 
interface identifier. 

6. A method according to any preceding claim 35 
wherein the application is arranged to communicate 
with the device driver via device manager means. 

7. A method according to any preceding claim 
wherein at least one said feature of the interface 40 
comprises a peripheral connected to the interface 
and the corresponding interface identifier com- 
prises the physical address assigned to that periph- 
eral, the logical identifier comprising a logical 
address assigned to the peripheral. 45 

8. A method according to Claim 8, wherein maintain- 
ing correspondence includes interrogating each 
peripheral to which a logical address is assigned to 
determine the physical address assigned to the so 
peripheral following a bus reset. 

9. A method according to Claim 4 and Claim 7 or 
Claim 8, wherein communicating the interface iden- 
tifier for a given peripheral comprises communicat- 55 
ing the physical address of the peripheral and also 
includes communicating a unique node identifier 
containing further information identifying the 



peripheral. 

10. A method according to any preceding claim, 
wherein at least one said feature of the interface 
comprises a channel of defined parameters availa- 
ble via the interface and the corresponding inter- 
face identifier comprises the interface channel 
number, the logical identifier comprising a logical 
channel identifier. 

11- A method according to Claim 10, wherein the 
device driver is arranged to receive a request from 
an application to allocate a channel of defined 
parameters and to return a logical channel identifier 
if allocation is successful. 

12. A method according to Claim 10 or 11, wherein the 
device driver is arranged to accept a preferred inter- 
face channel number and to allocate the preferred 
interface channel if available, and to allocate a free 
channel if the preferred interface channel is not 
available or if no preferred interface channel is 
specified. 

13. A method according to Claim 10, 1 1 or 12, wherein 
the device driver is arranged to receive an identifier 
of a preferred interface channel, to recognise a pre- 
determined key in place of a valid interface channel 
number as indicating that no preferred interface 
channel is specified, and to report an error to the 
application if other invalid interface channel num- 
bers are specified. 

14. A method according to Claim 10, 11, 12 or 13 
wherein the device driver is arranged to communi- 
cate the interface channel number to the applica- 
tion, and at least one other parameter selected 
from: the maximum rate allocated to the channel; 
the rate currently available; the number of connec- 
tions (if any) using the channel; and the identifiers 
of each connection using the channel. 

15. A method according to any preceding claim 
wherein the device driver is arranged to accept 
requests from an application to define one or more 
connections between physical devices attached to 
the interface by reference to logical addresses and 
logical channel identifiers. 

16. A method according to any preceding claim 
wherein the device driver is arranged to establish at 
least a broadcast connection. 

17. A method according to any preceding claim 
wherein the device driver is arranged to signal one 
or more events to an application, the events prefer- 
ably including reset of the bus (preferably beginning 
and end of reset) and a change in bus topology or 
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channel or connection parameters. 

18. A device driver for effecting communication 
between an application and an interface having at 
least one feature to which an interface identifier is s 
assigned, the or each interface identifier being lia- 
•ble to change after at least one event, the device 
driver comprising: 

means for storing at least one logical identifier 10 
corresponding to a respective interface identi- 
fier; 

means for providing the logical identifier to the 
application for directing communication associ- 
ated with the corresponding feature between 15 
the device driver and the application; 
means for maintaining correspondence 
between the or each logical identifier and the or 
each feature independently of the interface 
identifier assigned to the or each feature so 20 
that communication between the application 
and the device driver directed using a given 
logical identifier can remain associated with the 
corresponding given feature following a change 
in the assignment of the corresponding inter- 25 
face identifier to the feature. 

19. A device driver according to Claim 18, wherein the 
device driver is implemented in software, preferably 
executable by processing means which runs the or 30 
each application. 

20. A device driver acording to any of Claims 18 to 19, 
wherein the device driver is arranged to compile a 

list of logical identifiers and corresponding interface 35 
identifiers for all features meeting predetermined 
criteria. 

21. A device driver acording to any of Claims 18 to 20 
including means for communicating the interface 40 
identifier assigned to a logical identifier to the appli- 
cation on request. 

22. A device driver acording to any of Claims 18 to 21 , 
including means for accepting a request from an 45 
application to define connections between physical 
devices connected to the bus using at least one log- 
ical identifier in place of an interface identifier. 

23. A device driver acording to any of Claims 1 8 to 22, so 
wherein at least one said feature of the interface 
comprises a peripheral connected to the interface 
and the corresponding interface identifier com- 
prises the physical address assigned to that periph- 
eral, the logical identifier comprising a logical 55 
address assigned to the peripheral. 

24. A device driver acording to Claim 23, arranged to 



interrogate each peripheral to which a logical 
address is assigned to determine the physical 
address assigned to the peripheral following a bus 
reset. 

25. A device driver acording to Claim 21 and Claim 23 
or 24, wherein the means for communicating the 
interface identifier for a given peripheral comprises 
means for communicating the physical address of 
the peripheral and also includes means for commu- 
nicating a unique node identifier containing further 
information identifying the peripheral. 

26. A device driver acording to any of Claims 18 to 25, 
wherein at least one said feature of the interface 
comprises a channel of defined parameters availa- 
ble via the interface and the corresponding inter- 
face identifier comprises the interface channel 
number, the logical identifier comprising a logical 
channel identifier. 

27. A device driver acording to Claim 26 including 
channel allocating means arranged to receive a 
request from an application to allocate a channel of 
defined parameters and to return a logical channel 
identifier if allocation is successful. 

28. A device driver acording to Claim 27, wherein the 
channel allocating means is arranged to accept a 
preferred interface channel number and to allocate 
the preferred interface channel if available, and to 
allocate a free channel if the preferred interface 
channel is not available or if no preferred interfac 
channel is specified. 

29. A device driver acording to Claim 27 or Claim 28, 
wherein the channel allocating meansis arranged to 
receive an identifier of a preferred interface chan- 
nel, to recognise a predetermined key in place of a 
valid interface channel number as indicating that no 
preferred interface channel is specified, and to 
report an error to the application if other invalid 
interface channel numbers are specified. 

30. A method according to Claim 26, 27, 28 or 29 
including means for communicating the interface 
channel number to the application, and at least one 
other parameter selected from: the maximum rate 
allocated to the channel; the rate currently availa- 
ble; the number of connections (if any) using the 
channel; and the identifiers of each connection 
using the channel. 

31 . A device driver according to any of Claims 18 to 30 
including means arranged to accept requests from 
an application to define one or more connections 
between physical devices attached to the interface 
by reference to logical channel identifiers and, in 
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26 



the case of a request to define a point to point con- 
nection, by reference to logical addresses of the 
peripherals. 

32. A device driver according to any of Claims 1 8 to 3 1 , s 
including means arranged to establish at least a 
broadcast connection on request by an application. 

33. A device driver according to any of Claims 18 to 31 , 
including means for signalling one or more events 10 
to an application, the events preferably including 
reset of the bus (preferably beginning and end of 
reset) and a change in bus topology or channel or 
connection parameters. 

15 

34. A data processing system comprising: 



35. A data processing system according to Claim 34 
implemented in a receiver/decoder which includes 30 
means for receiving broadcast data, the interface 
being arranged for connection to a digital video 
recorder or digital display device or computer for 
display or storage of at least a portion of the 
received data. 35 

36. A receiver/decoder according to Claim 35, wherein 
the device driver means is arranged to cooperate 
with further device driver means for modifying the 
received data stream to produce a modified data ao 
stream for passing to said interface. 

37. A receiver/decoder according to Claim 35 or 36, 
wherein the interface conforms to the IEEE 1394 
standard or a variant thereof. 45 

38. A receiver/decoder according to Claim 35, 36 or 37, 
wherein the application is run in an interpreted lan- 
guage and the device driver is compiled. 

so 

39. A receiver/decoder according to Claim 35, 36, 37 or 
38, wherein the device driver is arranged to transmit 
commands for controlling a digital video recorder 
from the application and/or to receive data concern- 
ing the information stored on the digital video ss 
recorder. 

40. A receiver/decoder according to Claim 39, wherein 



the data to be communicated includes data in 
MPEG format. 

41. A device driver for use in a receiver/decoder having 
run-time-engine means for running an application 
and an IEEE 1394 interface to which at least one 
peripheral can be connected, the or each periph- 
eral capable of having a respective physical 
address assigned thereto, the interface being capa- 
ble of providing at least one communication chan- 
nel, the or each channel having $ respective real 
channel identifier assigned thereto, the real chan- 
nel identifier assigned to each channel and the 
address assigned to each peripheral being liable to 
change after a bus reset, the device driver being 
arranged for facilitating communication between 
the application and the IEEE 1394 interface, the 
device driver comprising: 

means for storing at least one logical address 
corresponding to a respective peripheral and 
for storing at least one logical channel identifier 
corresponding to a respective real channel; 
means for providing the logical address to the 
application for directing communication 
between the device driver and the application; 
channel allocating means for receiving a 
request from an application to allocate a com- 
munication channel, and, if a suitable commu- 
nication channel is available, for allocating the 
available suitable communication channel and 
providing a logical channel identifier to the 
application for directing communication 
between the device driver and the application; 
connection allocating means for receiving a 
request from an application to allocate a con- 
nection between peripherals attached to the 
interface using a channel identified by said log- 
ical channel identifier, and allocating a connec- 
tion if possible, wherein, in the case of a 
request for a point-to-point connection between 
peripherals, the peripherals are identified using 
said logical addresses; 

peripheral identity means arranged to receive a 
request from an application to identify a periph- 
eral corresponding to a given logical address 
and, in response thereto, to communicate the 
physical address of the corresponding periph- 
eral and to communicate a unique node identi- 
fier containing further information identifying 
the peripheral; 

event signalling means for signalling to the 
application one 0? a plurality of events including 
an interface bus reset; 

channel identity means arranged to receive a 
request from an application to identify a chan- 
nel corresponding to a given logical channel 
identifier and, in response thereto, to communi- 



run-time engine means for running an applica- 
tion; 

interface means for connection to at least one 20 
device, the interface having at least one feature 
to which an interface identifier is assigned, the 
or each interface identifier 
being liable to change after at least one event; 
and 25 
device driver means according to any of Claims 
18 to 33. 
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cate the interface channel identifer of the corre- 
sponding channel and to communicate at least 
one further parameter of the channel indicating 
at least one of maximum allocated channel 
bandwidth and currently available channel § 
bandwidth; 

wherein the channel allocating means is 
arranged to receive an Identifier of a preferred 
real channel and to allocate the preferred real 
channel if available, and to allocate a free" 10 
channel if the preferred real channel is not 
available or if the preferred real channel identi- 
fier comprises a pre-determined key in place of 
a valid real channel identifier and to report an 
error to the application if the preferred channel 15 
identifier corresponds to an invalid real channel 
identifier other than the pre-determined key. 

42. A receiver/decoder comprising means for receiving 
broadcast data; run-time-engine means for running 20 
at least one application; IEEE 1394 interface 
means for connection to at least one peripheral 
device; and device driver means according to Claim 
41 for interfacing the or each application to the 
IEEE 1394 interface means, and means for trans- 25 
porting received data to the IEEE 1394 interface. 
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